Fix FUTD check of copy items when building for debug #9130
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When the user presses F5 the Solution Build Manager (SBM) calls the Fast Up-to-date Check (FUTDC) twice, for some reason I don't fully understand. If you invoke build directly, it's only called once. In the debug case, the first of the two calls occurs *before* any SBM events are fired, which breaks an assumption that was made about the sequence of events. Specifically we assumed that the FUTDC would only be called between calls to `IVsUpdateSolutionEvents.UpdateSolution_StartUpdate` and `IVsUpdateSolutionEvents.UpdateSolution_Done`. But that's not the case when the user presses F5. It turns out that this surfaces an issue only for `CopyToOutputDirectory` items, as its only for these items that we use the shared `SolutionBuildContext` cache of timestamps. That cache helps considerably with the performance of Build Acceleration across the solution, where the same files are checked repeatedly within the solution. This change fixes the issue by creating a fake "solution build starting" event when we detect that no such event occurred prior to the FUTDC being called.
drewnoakes
added
the
Feature-Up-to-date
kvenkatrajan
approved these changes
Jun 28, 2023
This was referenced Jun 28, 2023
smitpatel
reviewed
Jun 28, 2023
src/Microsoft.VisualStudio.ProjectSystem.Managed/ProjectSystem/UpToDate/BuildUpToDateCheck.cs
Show resolved
Hide resolved
drewnoakes
added a commit
to drewnoakes/project-system
that referenced
this pull request
Jul 13, 2023
In some cases (such as when FUTDC logging is enabled) we run a validation pass to report to the user when their projects appear out of date despite just having been built. This feature alerts users to overbuild and provides useful diagnostic information to correct it. dotnet#9130 fixed a bug related to F5 builds. It introduced a race condition that can lead to the error reported in dotnet#9152. Our `CurrentSolutionBuildContext` value is set when the SBM starts the solution build, and cleared to `null` when it completes. Our validation logic runs async, and can complete after the SBM completes. In such cases, it can observe a null `CurrentSolutionBuildContext` value, which is not supported by the current code. This change captures the `CurrentSolutionBuildContext` value early on to ensure it's non-null when we need it later on, and passes the specific value down, preventing any issues from null values.
drewnoakes
added a commit
to drewnoakes/project-system
that referenced
this pull request
Jul 13, 2023
In some cases (such as when FUTDC logging is enabled) we run a validation pass to report to the user when their projects appear out of date despite just having been built. This feature alerts users to overbuild and provides useful diagnostic information to correct it. dotnet#9130 fixed a bug related to F5 builds. It introduced a race condition that can lead to the error reported in dotnet#9152. Our `CurrentSolutionBuildContext` value is set when the SBM starts the solution build, and cleared to `null` when it completes. Our validation logic runs async, and can complete after the SBM completes. In such cases, it can observe a null `CurrentSolutionBuildContext` value, which is not supported by the current code. This change captures the `CurrentSolutionBuildContext` value early on to ensure it's non-null when we need it later on, and passes the specific value down, preventing any issues from null values.
drewnoakes
added a commit
to drewnoakes/project-system
that referenced
this pull request
Jul 17, 2023
In some cases (such as when FUTDC logging is enabled) we run a validation pass to report to the user when their projects appear out of date despite just having been built. This feature alerts users to overbuild and provides useful diagnostic information to correct it. dotnet#9130 fixed a bug related to F5 builds. It introduced a race condition that can lead to the error reported in dotnet#9152. Our `CurrentSolutionBuildContext` value is set when the SBM starts the solution build, and cleared to `null` when it completes. Our validation logic runs async, and can complete after the SBM completes. In such cases, it can observe a null `CurrentSolutionBuildContext` value, which is not supported by the current code. This change captures the `CurrentSolutionBuildContext` value early on to ensure it's non-null when we need it later on, and passes the specific value down, preventing any issues from null values.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #9124
Fixes AB#1761194
Fixes AB#1827475
When the user presses F5 the Solution Build Manager (SBM) calls the Fast Up-to-date Check (FUTDC) twice, for some reason I don't fully understand. If you invoke build directly, it's only called once.
In the debug case, the first of the two calls occurs before any SBM events are fired, which breaks an assumption that was made about the sequence of events. Specifically we assumed that the FUTDC would only be called between calls to
IVsUpdateSolutionEvents.UpdateSolution_StartUpdateandIVsUpdateSolutionEvents.UpdateSolution_Done. But that's not the case when the user presses F5.It turns out that this surfaces an issue only for
CopyToOutputDirectoryitems, as its only for these items that we use the sharedSolutionBuildContextcache of timestamps. That cache helps considerably with the performance of Build Acceleration across the solution, where the same files are checked repeatedly within the solution.This change fixes the issue by creating a fake "solution build starting" event when we detect that no such event occurred prior to the FUTDC being called.
Microsoft Reviewers: Open in CodeFlow